Software tools for the automated management of distributed data processing systems are available, for facilitating the task of managing distributed data processing systems including large network of computers.
An example of automated system management tools are those directed to managing the distribution of software, e.g. from a central software distribution server, to a plurality of computers in a network; software distribution tools helps keeping the computers in the network up to date and aligned to one another in terms of the installed (release of) software packages.
Another example of automated system management tools are workload (also referred to as “job”) scheduling software tools, for controlling the execution of different work units (for example, jobs in a batch processing) by computers in a network.
Often, automated system management tools require a knowledge about the state of a target system (e.g., a computer in the network where a certain software package or application is to be installed, or a computer intended to execute a certain job), in order to successfully execute operations on that target system. Generally speaking, the knowledge about the target systems includes information about prerequisite hardware and software, available system capacity (in terms, for example, of available storage space on the local hard disk of the target system), and current configuration of the target system.
For example, in order for a software distribution application to upgrade a target system to a new level of a certain software package, the current level of the software resident on that target system needs to be known.
In order to get the necessary knowledge about the target systems, automated software distribution tools typically run regular inventory scans, and gather information about all the target systems in a network in a central archive.
A known approach to perform software inventory scans makes use of the concept of “signature”: a target system, for example the local file system thereof, is thoroughly scanned, and the names and sizes of the files found in the local file system are compared to a list of signatures, where a signature includes information about the name and the size of a specific file which form the software prerequisite the presence of which on the target system being scanned is to be assessed.
However, this approach is highly intrusive to the target systems, due to the impact inherent in performing a thorough scan on the system being scanned, an operation which is highly resource-consuming. To limit the impact on target systems of resource-intensive scans, the scans are generally rather infrequent, but this has the consequence that the inventory information that is available at the central archive can be stale; due to this, the desired distribution of software may fail.
Known job scheduling applications do not maintain inventory information, nor do they check for the presence of prerequisites on a target system before scheduling the execution, or executing a job on the target system. Nevertheless, a job scheduling application can successfully submit a job for execution by a target system provided that the target system possesses the necessary hardware and software prerequisites required for executing that job, available system capacity so as to be able to complete the intended work within a predetermined deadline time, and the appropriate system configuration to meet the requirements of the job to be executed. Missing such information, the execution of a job submitted to a target system may fail, with the consequence that a whole batch workload plan may be disrupted. Recently, the maintenance of a limited inventory repository for hardware characteristics of the target systems has been proposed, with the possibility of executing software prerequisite checks immediately before the execution of the jobs. This limits the impact of inventory scans on the target systems (software inventory scans generally have a much greater impact on the target systems than hardware inventory scans), but the assessment of the software prerequisites is left to the last moment, with the possibility that a job cannot be executed on a certain target system missing the prerequisite software, and that software provisioning is necessary, or that the job needs to be submitted for execution to a different target system, which itself may lack the required prerequisite software; the result is a waste of time.